home *** CD-ROM | disk | FTP | other *** search
/ Loadstar 210 / 210.d81 / t.speed basic < prev    next >
Encoding:
Text File  |  2001-01-01  |  4.4 KB  |  164 lines
  1. u
  2.        BYTES: SPEEDING UP BASIC
  3.  
  4.            by Maurice Jones
  5.  
  6.  
  7.     I am interested in efficient
  8. BASIC. My idea is to promote efficient
  9. modeling, to keep the code short, and
  10. to save time doing work while the user
  11. reads opening screens and the like.
  12. Considerations of what time intervals
  13. were needed for each task led me to
  14. consider questions of efficiency which
  15. depend on the way the machine works.
  16.  
  17.     There was considerable attention
  18. to this sort of thing in the
  19. literature about the 64, but it is
  20. riddled with half-truths and full-
  21. blown falsehoods. As late as the
  22. summer of '88, an editor of a print
  23. magazine reported a bug in the 64. The
  24. "bug" was simply his ignorance of some
  25. very fundamental principles of
  26. computing.
  27.  
  28.     Now let me say that I am NOT an
  29. expert; I am a student. What I did was
  30. study the question and conduct a LOT
  31. of [experiments]. I examined a LOT of
  32. code and read from the West and Leemon
  33. books. These are things you too can
  34. do.
  35.  
  36.  
  37.     I began my investigation by
  38. designing a short program to test the
  39. validity of such statements as
  40. "Multiply is faster than divide" and
  41. "Variables are faster than numbers."
  42.  
  43.     A funny thing happened on the way
  44. to enlightenment. It appears that some
  45. of these statements are wrong and
  46. others need qualifications. As is
  47. usual in life, the questions are not
  48. as easily answered as we would like.
  49.  
  50.     In order to have any chance of
  51. understanding, we must examine the
  52. details of how a BASIC program is
  53. stored and executed by the 64.
  54.  
  55.     On power-up the computer reserves
  56. memory from 2048 through 40959 for
  57. BASIC. The code is stored first,
  58. starting at 2049 and continuing as far
  59. as needed. When the program is RUN,
  60. the computer reads the first line of
  61. code and acts on it. If the code
  62. causes a simple variable to be stored,
  63. the information is stored in the first
  64. seven bytes following the end of the
  65. code.
  66.  
  67.     As each new line is executed,
  68. additional simple variables are stored
  69. IN THE ORDER THEY ARE ENCOUNTERED.
  70. These new variables will not overwrite
  71. the previous variable, but each will
  72. use the next seven bytes. In fact,
  73. once a variable is stored it will
  74. remain there for the rest of the run
  75. unless a CLR statement is issued.
  76.  
  77.     The term "simple variable" is used
  78. here to mean any variable, string or
  79. numeric, which is not subscripted.
  80. Both the name and the value of numeric
  81. variables are stored in the seven
  82. bytes. String variables are stored in
  83. the same area but in a different way,
  84. which will be discussed next month.
  85.  
  86.     Each time a new array is needed,
  87. it is stored starting in the next
  88. space after the most recent variable.
  89. From this point on, each time a new
  90. variable is needed, ALL arrays will be
  91. moved up seven bytes to make room for
  92. the new variable.
  93.  
  94.     This fact has consequences which
  95. seem to have received little
  96. attention. It is the usual practice to
  97. DIM arrays in the beginning of
  98. programs and introduce variables only
  99. when needed. In much of the code I
  100. examined the arrays would be moved
  101. over fifty times.
  102.  
  103.     DIM statements cause variables to
  104. be stored, whether they be simple
  105. variables or array variables. We shall
  106. see how we can use this fact to make
  107. our programs more efficient.
  108.  
  109.     Much more discussion will
  110. eventually be needed as the study
  111. unfolds, but we are now ready to run
  112. the demo from the RUN IT option.
  113.  
  114.     The RUN IT option is a quick and
  115. dirty program which will allow you to
  116. read some information screens and run
  117. two demos. The demos are described by
  118. the information screens. Please read
  119. these screens carefully and run the
  120. demos more than once if you need to.
  121.  
  122.     I believe that the following
  123. statements are fully proved by the
  124. demos:
  125.  
  126.  
  127.    1. The number of variables used
  128. will have a significant effect on the
  129. speed of the program.
  130.  
  131.    2. If a program contains large
  132. arrays (or many smaller arrays or some
  133. combination of these), the speed of
  134. the program will be significantly
  135. affected by variables which are
  136. introduced AFTER the arrays are in
  137. place.
  138.  
  139.    3. The order in which variables are
  140. introduced in respect to each other
  141. can be significant. If the variables
  142. which are introduced late are heavily
  143. used, the speed of execution will be
  144. slowed.
  145.  
  146.     In part II next month, I will
  147. discuss string storage and suggest a
  148. few more BASIC speed techniques.
  149.  
  150. Bibliography:
  151.  
  152.    1. R.C. West, PROGRAMMING THE
  153.    COMMODORE 64, COMPUTE!
  154.    Publications, INC., Greensboro,
  155.    N.C., 1985
  156.  
  157.    2. Sheldon Leemon, MAPPING THE
  158.    COMMODORE 64, COMPUTE!
  159.    Publications, INC., Greensboro,
  160.    N.C., 1984
  161.  
  162.  MJ
  163.  
  164.  
  165.